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ABSTRACT 


Systems engineering (SE) discipline has revolutionized the way engineers and managers 
think about solving issues related to design of complex systems. With continued 
development of state-of-the-art technologies, systems are becoming more complex and 
therefore, a systematic approach is essential to control and manage their integrated design 
and development. This complexity is driven from integration issues. In this case, sub- 
systems must interact with one another in order to achieve integration objectives, and also 
achieve the overall system’s required performance. Systems engineering process 
addresses these issues at multiple levels. It is a technology and management process 
dedicated to controlling all aspects of system life cycle to assure integration at all levels. 

The Advanced Integration Matrix (AIM) project serves as the systems engineering and 
integration function for the Human Support Technology (HST) program. AIM provides 
means for integrated test facilities and personnel for performance trade studies, analyses, 
integrated models, test results, and validated requirements of the integration of HST. The 
goal of AIM is to address systems-level integration issues for exploration missions. It will 
use an incremental systems integration approach to yield technologies, baselines for 
further development, and possible breakthrough concepts in the areas of technological 
and organizational interfaces, total information flow, system wide controls, technical 
synergism, mission operations protocols and procedures, and human-machine interfaces. 

This report provides the summary of results based on the proposed SOW during the 2004 
fellowship at NASA’s Johnson Space center for NFFP. These tasks were: 

1. Benchmarking and the evaluation of systems engineering processes in order to 
identify best practices and lesson learned. 

2. Propose a SE process template for the identification of functional requirements 
and its decomposition for human life support systems. 
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INTRODUCTION - ADVANCED INTEGRATION MATRIX (AIM) 


The Advanced Integrated Matrix (AIM) project attempts to provide SE&I services to 
highly advanced and complex projects (e.g. missions beyond Lower Earth Orbit or LEO) 
through ground-based testing and integration. The goal of the AIM is to develop the 
enabling environment and tool for gap analysis and commonality. The roadmap to AIM is 
through incremental implementation. The incremental approach evolving from a single- 
enterprise into a multi-enterprise, multi-center concern focused on developing and testing 
integrated mission concepts. AIM will initiate with projects with low level of complexity 
for integration and testing and then gradually evolve into a full mission scenario through 
“fly the mission on the ground ” concept. Figure 1 conceptualizes this concept. 



Figure 1. Moon and Mars “fly the mission on the ground” Configurations 1 

This incremental approach will generate the lessons learned and baselines for further 
designs of more complex systems. The possibility of identifying new breakthrough 
managements concepts and technology to support interfaces, information flow and 
sharing, managements, controls, operations and procedures, and man-machine interfaces 
are the goal of the this approach. This would require participations from different 
programs in the agency. AIM will 2 : 

• Address system-level integration and interface issues to support agency 
commitment to an exploration mission 

• Investigate issues common to multiple vehicles, architectures, and mission 
scenarios, and develop solutions in a scalable format 

• Aggressively pursue participation from academia and other NASA Centers to 
address Agency’s Strategic Plan. 

AIM will collect the scientific and technological knowledge of individual projects into an 
integrated ground-based test environment where system-level interactions are studied and 
optimized for commonality, performance efficiency, cost and mass savings. The Office 


1 D. Henninger, Integrity: A Program Concept, Johnson Space Center, NASA, 2002. 

2 G. Thomas, AIM Project Quarterly Report, AHST Program, Johnson Space Center, NASA, 2003. 
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of Biological and Physical Research (OBPR) has authorized initiation of the formulation 
phase. The purpose is to identify and solve system-level integration issues for exploration 
missions beyond Low Earth Orbit through design and development of a ground-based 
facility for developing an integrated system for joint human-robotic missions. 


PART I - SYSTEMS ENGINEERING PROCESS AND GENERIC MODELS 

Past experience has shown that lack of planning and clear identification of objectives has 
been the major problem associated with the design and development of any complex 
system. This approach has resulted in a system’s lack of performance and finally design 
failure. Traditionally, systems have been developed based on “ Deliver now and Fix 
Later. 3 ” This process has suffered from lack of clear planning which resulted in failure 
and high cost of design modifications. In this scenario, requirements at the systems level 
were kept general in order to reduce complexity to allow for new technology integration. 
This has routinely evolved into last minute modifications that impacted the schedule and 
cost. Decisions made at the early stages of development life cycle will significantly 
impact the overall life-cycle including cost and system’s effectiveness. Therefore, there is 
a need for a disciplined approach for integrated design and the development of new 
systems. In this case, all aspects of the development are considered early in the process 
and used for continuous improvement. Systems Engineering is “77ie effective application 
of scientific and engineering efforts to 1) transform an operational need into a defined 
system configuration through the top-down iterative process of requirement analysis, 
functional analysis and allocation, synthesis, design optimization, test, evaluation and 
validation, 2) integrate related technical parameters and ensure the compatibility of all 
physical, functional, and program interfaces in a manner that optimizes the total 
definition and design, and 3) integrate reliability, maintainability, usability, safety, 
serviceability’, disposability to meet cost, schedule, and technical performance 
objectives 4 . Systems engineering is also considered a process for Managing Technology. 
System engineering process has evolved in seven different paradigms . A summary of 
these processes are discussed below. 

1. Build-Test-Fix: This method consists of three basic steps, fabricate a design, test 
the system, and then operate. This method is typically used for in-house software 
development where the customer is also the developer. It is considered to be a simple 
but effective approach. Although, it lacks the requirements analysis phase that makes 
it not suitable for any complex systems design. 

2. Staircase: The Staircase method allows for better management and control of system 
development. This method is considered to be a systematic flow through the SE 
process. It is well suited for the developments of existing systems variants. In this 


3 Benjamin S. Blanchard, Systems Engineering Management, Wiely Interscience, 1998. 

4 Systems Engineering Fundamentals, Defense Acquisition University Press, 2001. 

5 Norman B. Reilly, Successful Systems Engineering for Engineers and Managers, Kluwer Academic 
Publishers, 1993. 
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case, already developed requirements are modified. The export version of a military 
aircraft is an example this concept. Requirements-Specification-Design-Fabrication- 
Testing-Acceptance-Operate area steps in the staircase SE cycle. 

3. Waterfall: This method improves the staircase method by adding feedback loops 
between successive stages as shown in Figure 2. Through these feedbacks, each stage 
is capable of gaining knowledge from the subsequent stages. The success of this 
model is dependant on understanding and processing revisions through feedback 
analysis. 



Figure 2. Waterfall Systems Engineering Process Model 

4 . Early Prototype: The early prototype process is an extension to the staircase with 
feed back cycle. This method is used when it is difficult for customer to identify 
requirements, but could recognize them through some model or prototype 
representation. The advantage of this method is due to direct interaction between 
stakeholders. Some of the difficulties with this approach are 1) the initial prototype 
could discourage the customer 2) it suggests an unattainable goals and 3) prototype 
design becomes the main objective rather than the actual customer’s need. 

5. Spiral: The Spiral method, as shown in Figure 3 is an extension to the early prototype 
concept. The primary advantage of the spiral method is the detailed development of 
requirements, specifications, and designs. The significant challenge for the spiral 
method is managing the prototype transitions. Some of the advantages are: 

• Risk-driven sequential phases with user involvement. 

• Considers highest risks issue first (Requirements understanding, Technical 
feasibility and System operations). 

• Cycles of risk-driven phases, spiral around and end with a final waterfall wrap. 

6. Rapid Development: The success of this process dependent on fast-paced innovation 
(RSDFTAO — RSDFTAO...) while completing multiple small starts to the final 
system. This process requires cross-functional teams with the ability to work across 
the functional boundaries. 
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Figure 3. Systems Engineering Spiral model 6 

7. Integrated: Integrated or concurrent development method consists of cross- 
functional teams with members from all of the functional areas working closely 
together, sharing details of their portion of the design as it progresses, and developing 
all aspects of the system simultaneously. The result is overlapping and managing the 
overall life cycle. Concurrent Engineering (CE) is defined as the systematic and 
integrated approach to systems life cycle design. CE is also known as the Design for 
Life Cycle model. Concurrent engineering is the implementation of parallel designs 
by cross-functional teams including suppliers. Without empowered team members 
and the free flow of communications, this method will not function. Figure 4 
illustrates an overview of the integrated SE infrastructure. Table 1 lists partial 
comparison among these models. 

A model that is typically used to define the critical elements of SE process is the Systems 
Engineering Capability Maturity Model (SE-CMM) 7 . These elements consist of activities 
which define ‘ what ’ has to be done. Table 2 lists these tasks. Tasks for design and 
development are listed in engineering group, project elements provide the management 
infrastructure and finally the organization elements provide the business infrastructure to 
support systems engineering effort. 


6 B. W. Boehm, Spiral Model of Software Development, Tutorial Software Project Management edited by 
R. H. Thayer and M. Dorfman, IEEE Press, 1988. 

7 Systems Engineering Capability Maturity Model SM , Version 1.1, Software Engineering Institute, Carnegie 
Mellon University, 1995. 
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Figure 4. Integrated Systems Engineering Infrastructure 
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Table 1. SEP sample comparison, strong (++), average (+), none (0), low (-) very low(-) 
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Table 2. SE-CMM Model 
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SYSTEMS ENGINEERING SAMPLE PROCESS MODLES 


“Vee” Process is widely used by many industries (Figure 5). 



Figure 5. “Vee” Process as applied to NASA Projects 8 

This concept is based on the iterative and parallel processes on the left hand side that will 
manage the verification functions on the right hand side. Verification is completed in a 
serial fashion, resulting in minimal rework. This method is cost effective and improves 
the success of the project. It also provides the necessary infrastructure for alternative 
design analysis and selection. A system that fits the requirements with best performance, 
voiced by the stakeholders. It is believed that by using this approach the probability of 
design of a reliable and satiable system is high 9 . Within the “Vee” process, the 3-Bubble 
Method (Figure 6) assures that the design performance and feasibility (schedule) are 
continuously compared with the requirements. This allows for analysis of alternative 
designs against the verified requirements. 


OenKlc Systems EnijIMorffig process 



Figure 6. 3-bubbles method 10 


8 K Forsberg, H. Mooz and H. Cotterman, Visualizing Project Management: A Model for Business and 
Technical Success, 2 nd Edition, Wiley and Sons, 2000. 

9 Ford Design Institute, Systems Engineering Fundamentals Course,, Ford Motor Company, 2000. 

10 Ibid. 
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The International Council in Systems Engineering, INCOSE , defines the Systems 
Engineering Process as "... an iterative process of technical management, acquisition and 
supply, system design, product realization, and technical evaluation at each level of the system, 
beginning at the top (the system level) and propagating those processes through a series of steps 
which eventually lead to a preferred system solution. At each successive level there are 
supporting, lower-level design iterations which are necessary to gain confidence for the decisions 
taken. During each iteration, many concept alternatives are postulated, analyzed, and evaluated 
in trade-off studies. There are many cross-coupling factors, where decisions on one subsystem 
effect other subsystems 11 .” INCOSE model is illustrated in Figure 7. 
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Figure 7. INCOSE Systems Engineering Model 12 


The Department of Defense (DoD) defines the systems engineering process as the 
transformation of the operational needs and requirements into an integrated system 
design solution through concurrent consideration of all life-cycle needs. This process will 
ensure the compatibility and integration of all physical interfaces and system definition 
and design reflect the requirements for all system elements (hardware, software, data, 
people, etc.). Finally, the SE process will identify and manage technical risks associated 
with the system development. Figure 8 illustrates the DoD SE process. Cost as an 
Independent Variable Concept (CAIV) is defined in Section 3.3.4 of DoD 5000.2-R, 
as:“. . . a process that helps arrive at cost objectives (including life-cycle costs) and helps 
the requirements community set performance objectives. The CAIV process shall be used 
to develop an acquisition strategy for acquiring and operating affordable DoD systems 
by setting aggressive, achievable cost objectives and managing achievement of these 
objectives. Cost objectives shall also be set to balance mission needs with projected out- 
year resources, taking into account anticipated process improvements in both DoD and 
defense industries." Cost in this process is a constraint. Identification and use of viable 
range of alternatives with knowledge of real and potential impacts, is essential for making 


1 1 International Council on Systems Engineering (INCOSE) SE Handbook Working Group, 2000. 

12 Ibid. 



the right decisions to meet stakeholders VOC while minimizing the Total Ownership 
Cost (TOC). 



Figure 8. DoD SE Process Cycle 13 


CAIV principle, as proposed by USAF, is further decomposed into five pillars 14 . Figure 9 
illustrates these five pillars. 
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Figure 9. CAIV Process Pillars 15 


CAIV is based on capability-based requirements. In this case, user must first define 
“what” the system needs to do and how subsystems are allocated. Cost Performance 
Integrated Product Team (CPIPT) is a major component of the CAIV process. This team 
performs cost-performance-schedule tradeoffs leading to CAIV-based cost, performance, 
and schedule objectives. The CPIPT and stakeholder work closely together to resolve 
issues and decide on the final range and objective values for schedule cost and 


13 Systems Engineering Fundamentals, Defense Acquisition University Press, 2001 . 

14 Col. M. A. Kaye (USAF), Lt. Col. M. S. Sobota (USAF), D. R. Graham, A. L. Gotwald, “Cost as an 
Independent Variable (CAIV) Principles and Implementation," American Institute of Aeronautics and 
Astronautics, 1999. 

15 Ibid. 
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performance. The total life cycle cost is closely monitored. TOC in CAIV is LCC. Risk 
management is an important part of the CAIV process. Program management and means 
for measure of progress assures the success of CAIV process. Simulation-Based 
Acquisition Concept (SBA) is the integrated and collaborative approach to systems 
design and through computer-based modeling and simulation. SBA concept is based on 
the DoD acquisition reform initiative. The new process as defined by DoD 5000.1, 23 
Oct 2000 consists of “ an acquisition process in which DoD and Industry are enabled by 
robust, collaborative use of simulation technology that is integrated across acquisition 
phases and programs .” SBA concept is based on collaborative engineering concept and 
environment 16 . Industrial partners, academia experts and government agencies will 
closely collaborate using COTS, technologies, developed methodologies and resources. 
This will reduce the development time and cost associated increased performance and 
functionality. Five principal architectural concepts used for SBA implementation are: 

1 . Collaborative Environment 

2. Collaborative Environments Reference Systems Architecture 

3. Distributed Product Descriptions 

4. DoD/Industry Resource Repository 

5 . Data Exchange F ormat 

SBA is not the replacement for systems engineering process. It is a distributed and 
integrated approach to design using the systems engineering principles. It is a modeling 
and simulation (M&S) technique used to support managers during their decision making 
process. It must maintain the integrity and security of all shared data including 
responsibility and accountability at all levels of proprietary and security. 



Figure 10. SBA infrastructure *' 


16 Simulation Based Acquisition; A New Approach, Defense Systems Management College Press, 1998. 

17 J. E. Coolahan, F. T. Case, Lt. Col. R. J. Hartnett, Jr., (USAF), “The Joint Strike Fighter (JSF): Strike 
Warfare Collaborative Environment (SWCE)f Proceedings of Fall Simulation Interoperability Workshop, 
2000. 
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THE JOINT STRIKE FIGHTER PROGRAM 


JSF program goal is to develop an affordable family of multi-role attack aircraft with 
high commonality. JSF has been described as a supersonic, single-engine, single-seat 
airplane with F-16/F/A-18 class performance and stealthy. The three JSF variants are a 
conventional takeoff and landing (CTOL); a carrier-based attack (CV) variant and a 
STOVL replacement. The Air Force may also buy some STOVL variants to replace its 
A- 10s. (Figure 11). 



CTOL configuration 


Figure 11. Lockheed Martin JSF Family for Next Generation of Military Fighters 

Modeling and simulation (M&S) concept has been significantly used for the JSF program 
through Program Definition and Risk Reduction (PDRR) to integrate warfighters and 
maintainers into the development process early in the design life cycle. The objective is 
to reduce requirements changes and development costs. JSF program charter focused on 
six key initiatives: 

• Establishing an integrated team of users and developers 

• Facilitating evolution of fully developed and validated operational requirements 

• Evolving requirements over time 

• Reducing development, procurement, and support costs 

• Performing tradeoff analyses of critical user defined performance parameters 

• Conducting unprecedented levels of simulation 

Within the four major JSF requirement (lethality, survivability, supportability, and 
affordability) 34 attributes are identified. These are, acquire the target, generate sorties, 
situational awareness, countermeasures, ID the target, weapon/sensor integration, 
accurate navigation, mission level intelligence, pass/receive timely information, assess 
battle damage, route planning, emissions control, maintainability, carrier suitability, inter 
operability, basing flexibility, all weather/night capability, multi-role capability, weapon 
carriage versatility, mission flexibility, accuracy, radar cross section, range, logistic 
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footprint, payload, infrared signature, speed, maneuverability, electro-optical signature, 
redundancy, hardening, acoustic signature, reliability, and ferry range. The JSF attributes 
are the combination of functions, operational flexibility, operational constraints, and 
parameters. Simulation modeling and virtual prototyping has allowed the Joint Strike 
Fighter (JSF) concept demonstration for assembly to be accomplished with fifty percent 
reduction in staffing and time compared to actual planned levels 18 . “ For JSF 
developments, simulations have improved the mechanical tolerances where the originally 
projected shim stock weight of 40 lbs per aircraft, as in the F-16, was reduced to less 
than 1 pound. 19 “ Cost was considered to be a major criteria during JSF requirement 
analysis phase. It was used as criteria for trade-studies. JSF is developed based on the 
simulation and acquisition program concept and collaborative engineering. Simulation 
was extensively used during the requirements development process, and will be used 
throughout the program. Virtual prototyping and collaborative engineering was used to 
integrate all stakeholders into the systems engineering process. Analysis provides the 
incremental approach for complete system definition, design and integration. 

PART II: ALS Functional Analysis and Decompositions within AIM 

The life support system provides for crew the necessary resources for activities such as 
food, water and waste management. Figures 12 and 13 illustrate the level of interface 
between the crew, life support sub-systems and the four main sub-systems interaction of 
ALS. 



Figure 12. Crew and the Life Support System Interface 20 


A three phase methodology was proposed to further identify and decompose the life 
support functions. The steps within the methodology are: 

1 . Understand the System 

• Collect Information about the problem 


18 Boeing.com/defense-space/military/jsf/Iean_mfg.html 

19 Building A Business Case for M&S, Acquisition Review Quarterly — Fall 2000 

20 D. Henninger, “Lunar Base Life Support and Crew Health, ” Lunar Base Handbook , McGrawHill, 1999. 
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• Organize the Requirements 

• Develop the Theme 

2. Define Function 

• Select requirement for functional analysis 

• Define Functions 

• Define function criteria 

3. Decompose and Systematize Functions 

• Identify main functions 

• Relate functions 

• Check functions series 

• Establish criteria 
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Figure 13. Life Support Sub-Systems 21 

To define the scope of the life support system, the affinity diagram was used to collected 
data from the team members. Affinity analysis is a process used to gather large amounts 
of data based on opinions, concepts and issues and then organizes them into sets of 
groups using their natural relationship. The Affinity process uses brainstorming sessions 
to generate and collect group ideas. Steps for developing the affinity diagram are: 


1) Identify the problem 

2) Generate ideas 

3) Display ideas 

4) Sort ideas into groups 

5) Create header cards 


21 S. Doll, “Life Support Functions and Technology Analysis for Future Missions, “ Proceeding of 20 <h 
Intersociety Conference on Environmental Systems, SAE Technical Paper901216, 1990. 
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6) Draw clustered groups and finished diagram 


The issue of “How to Support Crew Life Beyond LEO?” was used to collect data from 
the team. The team included engineers, systems engineers and managers from both 
NASA and Lockheed. Figure 14 illustrate the results in the affinity diagram format. 



Figure 14. Result of the Affinity Analysis 


Defining the functions of a given system involves asking the question of “What is it 
action?” Functions are typically expressed using the verbal model that combines a verb 
and a noun. Typically function is characterized by the degree to which it performance is 
required and fulfilled under certain condition. These are called criteria for functions; (e.g. 
mile/gallon). The criteria for functions are determined using the so-called 5W1H 
questions; what, who, when, where, why and how much. After further analysis of the 
affinity data and its interpretation to the requirements, the following partial functional 
requirements for ALS were identified: 


• Maintain a safe, habitable and operational environment. 

• Provide resources for atmosphere, maintenance, crew consumption, and crew 
hygiene. 

• Manage wastes for resource recovery. 


Axiomatic design was used for further decomposition, systemization and mapping of the 
technologies. Axiomatic design provides the scientific basis and structure design 
approach to design identification, decomposition and mapping 22 . AD is a structured 
approach that associates the needs, requirements and solutions for system design 
problem. In Axiomatic Design approach, the customer wants is processes in such a way 


22 Num Suh„ “The Principles of Design ,” New York: Oxford University Press, 1990. 
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that lead to the definition of the functional requirements (FRs) which then identifies the 
design parameters (DPs). The FRs identify what needs to be done and DPs identify how 
each FR is implemented. Each DP is decomposed into lower level of FRs through 
zigzagging for further identifications of DPs and FRs 23 . This decomposition process 
continues until the DPs explain the design; design is complete. Axiomatic design was 
used functional requirements analysis of ALS. Sample results for decomposition and 
traceability chart is listed in Figures 15 and 16. 
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Figure 15. Partial listings of the ALS Decomposed functions 









CONCLUSION AND FUTURE PLANS 


The mission of AIM is also to consider the HST technologies as an integral part of 
Advanced Life Support system development. The process focusing on the embodiment of 
technologies as part of the system’s design is known as technology-push. This approach 
requires a new engineering paradigm that considers technology feasibility analysis and its 
integration into the customer-pull traditional SE process in order to validate the 
performance(s) of the technology within the overall system using parallel structure. Since 
no structured approach is available for the technology push method of design, potential 
risks of missing the mission needs and requirements are high. Despite these risks a 
successful process has significant benefits. A new engineering paradigm is proposed 24 to 
consider perform this task. It will perform technology feasibility analysis and integrate it 
into the ALS SE development process in order to validate the performance(s) of the 
technology within the overall system using parallel structure. A step-by-step process is 
used to guide the systems engineer through testing and integration of the ALS 
technologies and then identifying corresponding HST design parameters. The three stages 
proposed for technology capability and feasibility analysis are 1) Technology 
Evaluations, 2) Technology Opportunity Identification, and 3) Technology Mapping as 
shown in Figure 17. 



Figure 17. Integrated TP and SE Process for ALS and HST Mapping Methodology 

Further research is necessary for the development and implementation of the proposed 
method. Potential sources of funding are being considered for the continuation. 


24 A. Kamrani, ALS Sub-Systems Design Integration & Testing within AIM, NFFP Directorate Proposal, 
(not funded), 2004. 
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